home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-atm-mtu-03.txt
< prev
next >
Wrap
Text File
|
1993-10-29
|
13KB
|
335 lines
Network Working Group Randall J. Atkinson
Request for Comments: DRAFT Naval Research Laboratory
<draft-ietf-atm-mtu-03.txt> 29 October 1993
Default IP MTU for use over ATM AAL5
Status of this Memo
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that
other groups may also distribute working documents as Internet
Drafts. This particular draft is a working document of the IETF's
"IP over ATM" working group. It is intended to eventually submit
this draft to the IESG for possible release as a standards-track RFC.
Internet Drafts are draft documents valid for a maximum of six
months. This Internet Draft expires on 29 April 1994. Internet
Drafts may be updated, replaced, or obsoleted by other documents at
any time. It is not appropriate to use Internet Drafts as reference
material or to cite them other than as a "working draft" or "work in
progress".
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Distribution of this memo is unlimited.
Default Value for IP MTU over ATM AAL5
Protocols in wide use throughout the Internet, such as the Network
File System (NFS), currently use large frame sizes. Empirical
evidence with various applications over the Transmission Control
Protocol (TCP) indicates that larger Maximum Transmission Unit (MTU)
sizes for the Internet Protocol (IP) tend to give better performance.
Fragmentation of IP datagrams is known to be highly undesirable.
[KM87] It is desirable to reduce fragmentation in the network and
thereby enhance performance by having the IP Maximum Transmission
Unit (MTU) for AAL5 be reasonably large. NFS defaults to an 8192
byte frame size. Allowing for RPC/XDR, UDP, IP, and LLC headers, NFS
would prefer a default MTU of at least 8300 octets. Routers can
sometimes perform better with larger packet sizes because most of the
performance costs in routers relate to "packets handled" rather than
"bytes transferred". So there are a number of good reasons to have a
reasonably large default MTU value for IP over ATM AAL5.
RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which is
larger than 8300 octets but still in the same range. [RFC-1209] There
Atkinson [Page 1]
Internet Draft 29 October 1993
is no good reason for the default MTU of IP over ATM AAL5 to be
different from IP over SMDS, given that they will be the same
magnitude. Having the two be the same size will be helpful in
interoperability and will also help reduce incidence of IP
fragmentation.
Therefore, the default MTU for IP over ATM AAL5 shall be 9180
octets. All implementations compliant and conformant with this
specification shall support this default IP MTU value for use over
ATM AAL5.
Minimum Value for IP MTU over ATM AAL5
The smallest acceptable value for the IP MTU for use over ATM AAL5
is 576 octets. This value conforms with the requirements of the Host
Requirements RFC and is consistent with the IP specification. [RFC-
793, RFC-1122]. All ATM Forum compliant implementations of ATM
technology are capable of handling this restriction without
difficulty. This restriction is placed in order to minimise the
occurence for IP fragmentation, which is known to be harmful, and to
ensure support for future versions of IP that are currently in
development. Note that this minimum MTU does not place any lower
bound on the size of the IP datagram that may be transmitted by any
system. Rather, it ensures that all systems will handle IP datagrams
of size less than or equal to 576 octets without IP fragmentation.
Before such a small MTU value may be used, the requirements described
in the MTU NEGOTIATION section must be adhered to.
MTU Negotation for ATM AAL5
The ATM signalling protocol uses two different parts of the
Information Element named "AAL Parameters" to exchange information on
the MTU over the ATM circuit being setup [ATMF93a]. The component
named "Forward Maximum CPCS-SDU Size Identifier" contains the value
over the path from the calling party to the called party. The
component named "Backwards Maximum CPCS-SDU Size Identifier" contains
the value over the path from the called party to the calling party.
The ATM Forum specifies the valid values of this identifier as 1 to
65534 inclusive. Not all of those values make sense in the context
of IP over ATM as is explained in the preceding section, so not all
of those values may be used by implementations of this specification.
Note that the ATM Forum's User-to-Network-Interface (UNI) signalling
permits the MTU in one direction to be different from the MTU in the
opposite direction, so the ATM information elements might have
Atkinson [Page 2]
Internet Draft 29 October 1993
different values on the same connection.
Other MTU values for ATM AAL5 (i.e. other than the default value
specified above) shall not be used unless use of the other MTU value
was successfully negotiated using industry-standard ATM-specific
mechanisms (e.g. ATM Signalling Protocol) prior to being attempted.
If negotiation of the MTU value is attempted but fails, then the
default MTU value shall be used. If either of the above cited
information elements is not present in the ATM Signalling Protocol's
"SETUP" message, then the default MTU value shall be used for each
missing value. If the calling device erroneously sets the value of
either information element to 0, then either the default MTU value
shall be used or the party receiving the invalid value shall clear
the call with cause "Invalid Information Element Contents" being
indicated.
If the calling party wishes to use the default MTU but is willing
and able to negotiate an MTU size other than the default, it should
include the "AAL Parameters" information element with the default
values for the Maximum CPCS-SDU Size Identifier as part of the SETUP
message of the ATM signalling protocol [ATMF93b]. If the calling
party desires to use a different value than the default, it must
include the "AAL Parameters" information element with the desired
value for the Maximum CPCS-SDU Size Identifier as part of the SETUP
message of the ATM Signalling Protocol. The value of these
identifiers may range from 576 to 65535 octets in an implementation
of this specification. If the calling party is only willing to use
the default MTU value, the Maximum CPCS-SDU components must not be
specified in the SETUP message. The called party will respond using
the same information elements and identifiers in its CONNECT message
response [ATMF93c].
If the called party receives a SETUP message containing a "Maximum
CPCS-SDU Size Identifier" in the "AAL Parameters" information
element, it shall handle the Maximum CPCS-SDU Size Identifier as
follows:
a) If it is able to accept the proposed MTU values, it shall set
the values of the Maximum CPCS-SDU Size Identifier equal to the
proposed values and include that information in its CONNECT
message responding to the original SETUP message.
b) If it wishes a smaller MTU size than that proposed but greater
than or equal to 576, then it shall set the values of the Maximum
CPCS-SDU Size Identifier equal to the desired value in its
CONNECT message responding to the original SETUP message.
Atkinson [Page 3]
Internet Draft 29 October 1993
c) If it does not wish to negotiate the MTU, it shall not include
the Maximum CPCS-SDU Size Identifiers in its CONNECT message
responding to the original SETUP message.
If a called endpoint receives a SETUP message containing no
"Maximum CPCS-SDU Size Identifier" in the "AAL Parameters"
information element, it shall not include such an identifier in the
CONNECT message sent in response to the original SETUP message and
the default IP MTU for use over AAL5 shall be used by both parties.
If the called endpoint incorrectly includes the "Maximum CPCS-SDU
Size Identifier" in the CONNECT messages (e.g. because the original
SETUP message did not include such information) or it sets such an
identifier to a value less than 576 or more than the value of the
original SETUP message, then the calling party shall clear the call
with cause "Invalid Information Element Contents" being indicated.
Path MTU Discovery Required
The Path MTU Discovery mechanism is an Internet Standard and is an
important mechanism for reducing IP fragmentation in the Internet.
This mechanism is particularly important because new subnet
technologies, such as ATM, use default MTU sizes different from older
subnet technologies such as Ethernet and FDDI.
In order to ensure good performance throughout the Internet and
also to permit IP to take full advantage of the potentially larger IP
datagram sizes supported by ATM, all implementations that comply or
conform with this specification must also implement the IP Path MTU
Discovery mechanism as defined in RFC-1191 and clarified by RFC-1435.
Security Considerations
Security Considerations are not discussed in this memo.
References
[RFC-791] J. Postel, Internet Protocol, RFC-791, DDN Network
Information Center, September 1981.
[RFC-793] J. Postel, Transmission Control Protocol, RFC-793, DDN
Atkinson [Page 4]
Internet Draft 29 October 1993
Network Information Center, September 1981.
[RFC-1122] R. Braden (Ed.), Requirements for Internet Hosts --
Communications Layers, RFC-1122, DDN Network Information Center,
October 1989, pp.58-60.
[RFC-1191] J. Mogul & S. Deering, Path MTU Discovery, RFC-1191, DDN
Network Information Center, November 1990.
[RFC-1209] D. Piscitello, D & J. Lawrence, The Transmission of IP
Datagrams over the SMDS Service, RFC-1209, DDN Network Information
Center, March 1991.
[RFC-1435] S. Knowles, IESG Advice from Experience with Path MTU
Discovery, RFC-1435, DDN Network Information Center, March 1993.
[ATMF93a] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
Forum User Network Interface Specification, Version 2.4 (clean),
Document 93-620R3, Section 5.4.5.5, p. 174, 5 August 1993, ATM Forum.
[ATMF93b] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
Forum User Network Interface Specification, Version 2.4 (clean),
Document 93-620R3, Section 5.3.1.7, p. 149-150, 5 August 1993, ATM Forum.
[ATMF93c] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
Forum User Network Interface Specification, Version 2.4 (clean),
Document 93-620R3, Section 5.3.1.3, p. 146, 5 August 1993, ATM Forum.
[KM87] C. Kent & J.Mogul, "Fragmentation Considered Harmful", Proceedings
of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications
Technology, August 1987.
Acknowledgements
While all members of the IETF's IP over ATM Working Group have been
helpful, Vern Schryver, Rob Warnock, Craig Partridge, and Subbu
Subramaniam have been especially helpful to the author in analysing
the host and routing implications of the default IP MTU value.
Similarly, Dan Grossman provided significant help in clarifying the
optional ATM signalling procedure used to negotiate the IP MTU value.
Disclaimer
Author's organisation provided for identification purposes only.
This document presents the author's views and is not necessarily the
official opinion of his employer.
Atkinson [Page 5]
Internet Draft 29 October 1993
Author Information
Randall J. Atkinson <atkinson@itd.nrl.navy.mil>
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA
Atkinson [Page 6]